High-altitude pseudo-satellite neural network for unmanned traffic management

ABSTRACT

A HAPS platform may execute a neural network (a “HAPSNN”) as it monitors air traffic; the neural network enables it to classify, predict, and resolve events in its airspace of coverage in real time as well as learn from new events that have never before been seen or detected. The HAPSNN-equipped HAPS platform may provide surveillance of nearly 100% of air traffic in its airspace of coverage, and the HAPSNN may process data received from a drone to facilitate safe and efficient drone operation within an airspace.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of, and incorporates herein by reference in its entirety, U.S. Ser. No. 63/068,660, filed on Aug. 21, 2020.

FIELD OF THE INVENTION

The present invention relates, generally, to safe navigation for unmanned aerial vehicles (UAVs).

BACKGROUND

A UAV, commonly known as a drone or unmanned aerial system (UAS), and also referred to as a remotely piloted aircraft, is a flight vehicle without a human pilot aboard. Its path is controlled either autonomously by onboard computers or by the remote control of a pilot on the ground or in another vehicle. Drones have proliferated in number as recognition of their widespread and diverse commercial potential has increased.

Drones may make use of global positioning system (GPS) navigation functions, e.g., using GPS waypoints for navigation, and tend to follow preprogrammed flight paths. These may lead the drone to or around assets it will scan and inspect using onboard sensors. Under current Federal Aviation Administration (FAA) guidelines and regulations, drones can only operate in authorized areas. The speed and ease with which authorization may be obtained varies with the airspace and whether it is actively monitored by unmanned traffic management (UTM) and low-altitude authorization and notification capability (LAANC) systems. The drone operator must be in communication range of such systems to be able to send and receive airspace authorization requests and permissions in real time.

Drone systems may utilize a variety of onboard sensors (including one or more cameras, radiofrequency (RF) sensors, etc.) to monitor the operating environment, pre-calculate and follow a path to an asset to be inspected, and perform the inspection. Despite the presence of these sensors, the drone may not be equipped to use the data they provide to react to unplanned changes in flight path (e.g., to avoid unexpected obstacles or perform collision-avoidance maneuvers), or adapt to GPS drift that can affect waypoint accuracy. GPS drifts occur when a preprogrammed flight path fails to account for GPS drift vector calibrations and corrections. When the operator defines a flight plan with waypoints in the absence of such corrections, for example, the navigation system may take the drone off-course; even a small deviation may take all or part of the asset of interest outside the preprogrammed flight path and, consequently, the field of view of the onboard sensors.

Conventional drones may also fail to react to anomalies or unexpected conditions in the operating environment. The drone may cease collecting information, for example, if sensor readings fall below preset trigger thresholds, or may overcollect data if it veers off-course and begins recording sensor data before the target is actually reached.

Drone operation can be enhanced using high-altitude pseudosatellite (“HAPS”) platforms, also called a high-altitude, long-duration (“HALE”) platforms. These are unmanned aerial vehicles that operate persistently at high altitudes (of, e.g., at least 70,000 feet) and can be recharged by solar radiation during the day so they can remain in flight for prolonged periods of time to provide broad, satellite-like coverage of airspace. A HAPS drone equipped with RF communications payloads can offer vast areas of RF coverage—alone or in concert with existing communication satellite constellations or ground-based telecommunications networks, national airspace surveillance infrastructures, national airspace navigational aids, or individual air-traffic communication and surveillance systems—to offer connectivity and real-time communications and surveillance services to air traffic including drones.

HAPS platforms can be operated with less expense and greater flexibility than satellite constellations, which are not easily recalled for upgrades to meet changing bandwidth demands or augmented in number on short notice. In addition, satellites do not readily integrate with existing terrestrial air-traffic surveillance systems, making them less well suited than HAPS platforms for monitoring drone operation and maintaining the safe separation of drones and manned air traffic operating in the same airspace. Terrestrial alternatives such as telecommunication sites generally have short range and small areas of coverage, and once again, expanding coverage or capabilities is expensive and may not even be feasible due to features of the terrain or manmade structures.

At present, HAPS platforms are limited in terms of their ability to provide mission-level support to drones. While they can enhance safety and potentially aid navigation, they are not designed to help drones recover from path deviations to record all necessary measurements of a target asset without data overcollection.

SUMMARY

Neural networks are computer algorithms modeled loosely after the human brain and excel at recognizing patterns, learning nonlinear rules, and defining complex relationships among data. They can help drones navigate and provide mission support to ensure proper asset inspection without data overcollection. A HAPS platform may execute a neural network (a “HAPSNN”) as it monitors air traffic; the neural network enables it to classify, predict, and resolve events in its airspace of coverage in real time as well as learn from new events that have never before been seen or detected. The HAPSNN-equipped HAPS platform may provide surveillance of nearly 100% of air traffic in its airspace of coverage, and the HAPSNN may process data received from a drone to facilitate safe and efficient drone operation within an airspace. The HAPSNN also enables bidirectional connection and real-time monitoring so drones can better execute their intended missions.

Alternatively or in addition, the drone may execute a neural network to assist with inspection, surveillance, reporting, and other missions. In various embodiments, the invention makes use of unsupervised “deep learning” neural networks executed onboard low-altitude inspection drones. Such a drone inspection neural network (“DINN”) may monitor, in real time, the data stream from a plurality of onboard sensors during navigation to an asset along a preprogrammed flight path and/or during its mission (e.g., as it scans and inspects an asset). This neural network may communicate with unmanned traffic-management systems directly or through a HAPSNN, as well as with manned air traffic, to allow for safe and efficient drone operation within an airspace. Using a bidirectional connection to terrestrial and/or satellite-based communication networks, or to a HAPSNN, the DINN may request or receive real-time airspace change authorizations so it can adapt the drone flight path to account for airspace conflicts with other air traffic, terrain or obstacle conflicts, or to optimize the drone's flight path for more efficient mission execution. Importantly, the DINN can enable the drone to compensate for GPS drift or other course deviations, or unexpected target anomalies, by enabling target acquisition and locating all assets to be inspected.

One application benefiting from cooperation between a HAPSNN and a DINN is pinpointing of passive intermodulation (PIM) on active telecommunication structures. PIM comes from two or more strong RF signals originating with transmitters sharing an antenna run, transmitters using adjacent antennas, or nearby towers with conflicting antenna patterns. PIM shows up as a set of unwanted signals created by the mixing of two or more strong RF signals in a nonlinear device, such as loose or corroded connectors, cables, duplexers, circulators, damaged antennas or nearby rusted members such as fences, barn roofs or bolts. Other sources include poorly terminated or damaged cables with a seam in the shielding, and aging lightning arrestors. PIM can be time-consuming and difficult to detect using traditional probing methods. A combination of a DINN and HAPSNN that provides connectivity to unmanned traffic management can enable the drone to fly around the telecommunications asset autonomously and unsupervised to detect, classify, and pinpoint PIM sources. If the drone detects novel or unexpected readings, it may be able to resolve and classify the nature of the readings based on its training. When the drone inspection is complete, the drone, using the DINN, may fly to the next preprogrammed asset location and adapt its flight path in real time along the way to optimize its operation in the airspace.

Accordingly, in a first aspect, the invention relates to a platform for high-altitude flight and communication with UAVs. In various embodiments, the platform comprises a wireless transceiver; a computer memory; a communication facility for communicating, via the transceiver, with UAVs operating within a defined airspace; and a computer including a processor and electronically stored instructions, executable by the processor, for using data received from the UAVs as input to a predictor that has been computationally trained to identify actions to be taken based on a UAV state and a condition affecting its flight.

In various embodiments, the predictor is a neural network. The computer may be further configured for communication with air-traffic control infrastructure. For example, the UAV state may comprise a spatial position and a velocity, and the computer may be further configured to determine terrestrial features and their likelihood of interfering with current or future communications between a UAV and a terrestrial communication source and, if the likelihood exceeds a threshold, to establish a communication link bridging the UAV and the terrestrial communication source. The terrestrial features may, for example, be determined based on a locally or remotely stored map. In some embodiments, the computer is further configured to (i) predictively determine a need for an altered flight plan for the UAV, and (ii) cause the transceiver to wirelessly obtain authorization for the altered flight plan and thereupon communicate the authorized altered flight plan to the UAV.

The altered flight plan may avoid a possible hazard, e.g., a weather condition or a possible collision with another UAV. The he altered flight plan may permit unplanned inspection of a terrestrial asset.

In another aspect, the invention pertains to a method of controlling a defined airspace using a high-altitude pseudosatellite vehicle. In various embodiments, the method comprises the steps of wirelessly monitoring a state of at least one UAV operating in the defined airspace; detecting flight-affecting conditions in the defined airspace; using data received from the at least one UAV as input to a predictor that has been computationally trained to identify actions to be taken based on the UAV state and a detected flight-affecting condition; and causing the high-altitude pseudosatellite vehicle to responsively take the action.

In various embodiments, the predictor is a neural network. The action may include communication with air-traffic control infrastructure. The UAV state may comprise a spatial position and a velocity, and in various embodiments, the method further comprises the steps of determining terrestrial features and their likelihood of interfering with current or future communications between a UAV and a terrestrial communication source; determining that the likelihood exceeds a threshold; and thereupon establishing a communication link bridging the UAV and the terrestrial communication source. Terrestrial features may be determined based on a locally or remotely stored map.

In some embodiments, the UAV state comprises a spatial position and a velocity, and the method further comprises the steps of computationally determining a predicted need for an altered flight plan for the UAV; and thereupon wirelessly obtaining authorization for the altered flight plan and communicating the authorized altered flight plan to the UAV. The method altered flight plan may avoid a possible hazard such as a weather condition or possible collision with another UAV. Alternatively or in addition, the altered flight plan may permit unplanned inspection of a terrestrial asset.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and the following detailed description will be more readily understood when taken in conjunction with the drawings, in which:

FIG. 1 conceptually illustrates a HAPS providing surveillance and connectivity in a monitored airspace.

FIG. 2 conceptually illustrates the role of a HAPSNN in predicting the need for and providing communication links in a monitored airspace with obstacles or terrain blocking line-of-sight communications.

FIG. 3 conceptually illustrates the role of a HAPSNN in predicting the need for and proactively obtaining an expansion of authorized airspace for a drone transiting through a monitored region.

FIG. 4 conceptually illustrates HAPSNN prediction of the need for a flight-plan deviation and authorization therefor.

FIG. 5 conceptually illustrates a HAPSNN providing surveillance and connectivity in an airspace to relay signals from multiple navigational aids to air traffic that is out of range or blocked from receiving their signals.

FIG. 6 conceptually illustrates a HAPSNN providing surveillance and connectivity in an airspace to monitor and avoid airspace conflict.

FIG. 7 conceptually illustrates HAPSNN prediction of the need for a flight-plan deviation and authorization therefor in order to enable efficient execution of an inspection mission.

FIG. 8A is a block diagram of representative HAPSNN and DIINN architectures in accordance with embodiments of the present invention.

FIG. 8B schematically illustrates the manner in which a HAPSNN may support the operation of a DINN.

FIGS. 9A and 9B schematically illustrate generation of flight plans that execute an inspection mission, and which may change in real time as the drone performs the inspection.

FIG. 10 is an elevation illustrating various anomalies associated with an antenna that a drone in accordance herewith may identity.

FIG. 11 conceptually illustrates detection by a drone of an abnormal electromagnetic (EM) signature from a transformer.

FIG. 12 conceptually illustrates an in-flight drone reading stored data indicating an abnormality.

FIGS. 13A-13E schematically illustrate a process for establishing an optimal flight path through a complex inspection environment.

FIG. 14 schematically illustrates detection and classification of the centers of radiation of a plurality of antennas.

DETAILED DESCRIPTION

Refer first to FIGS. 1-7, which illustrate the functions performed by a conventional HAPS platform 105 and the manner in which these functions may be enhanced through operation of a HAPSNN. In FIG. 1, the HAPS platform 105 communicates with a plurality of cell towers representatively indicated at 108, a plurality of aviation control systems representatively indicated at 110, and a series of aircraft representatively indicated at 113; all of these systems and vehicles are within the defined airspace 115 that the HAPS platform 105 monitors. The HAPS platform 105 may also communicate with a plurality of drones 118 in the airspace 115, directly and/or via a cell tower. Finally, the HAPS platform 105 may communicate with satellites representatively indicated at 120, e.g., for geolocation to maintain a substantially fixed position. In this way, the HAPS platform 105 obtains and updates a complete snapshot of the airspace 115 and monitors air traffic therein, serving as a communication hub among the various intercommunicating entities in the airspace 115.

As seen in FIG. 2, as the HAPS 105 monitors the position, state, and velocity of the drone 118 and manned air traffic 133 that operate in the monitored airspace 115. The onboard HAPSNN recognizes that, given the operating altitude of the drone 118, terrain or other obstacles 205 will block line-of-sight communications between the drone 118 and the aviation control system 110 and even the aircraft 113. The obstacles 205 may be recognized and mapped in real time by the HAPS 105, but more likely they will be stored in a map accessible locally to the HAPS 105 or via a wireless link. More specifically, the HAPSNN may compute a likelihood of the obstacles 205 interfering with current or future communications between the drone 118 and the aviation control system 110; and if the likelihood exceeds a threshold, registering the need to establish a communication link bridging the drone 118 and the aviation control system 110. In that event, the HAPS 105 responsively obtains the state (position, including altitude, and trajectory) of the drone 118 by any suitable modality or combination thereof, e.g., observation, telemetry, signal monitoring and/or direct communication with the drone 118 and/or terrestrial air traffic control systems that monitor its flight.

As a result of this recognized need, HAPS 105 may enter the communication network as an intermediate node or relay messages (i.e., act as a transmission link) between the drone 118 and the aviation control system 110 (e.g., UTM and LAANC) or other ground-based air-traffic surveillance infrastructure. In the absence of the HAPSNN, the HAPS 105 would have operated reactively—e.g., if the drone 118 had previously been communicating with the HAPS 105 and the control system 110, the HAPS 105 could serve as a backup communication channel when direct communication between the drone 118 and the control system 110 is lost as the drone approaches the obstacle 205. The HAPSNN facilitates proactive, predictive intercession by the HAPS 105 even if no prior communication between the drone 118 and control system 110 has taken place. Based on stored or acquired knowledge of the terrain and the locations of fixed communication features within the airspace 115, as well as the computed trajectory of the drone 118 (which may have only just entered the airspace 115), the HAPSNN recognizes the need for communication between the drone 118 and the control system 110 and causes the HAPS 105 to establish a wireless link with itself as the hub. Similarly, based on knowledge of the terrain and the monitored altitudes of the drone 118 and the manned aircraft 113, the HAPSNN may cause the HAPS 105 to establish a wireless link between the drone 118 and the aircraft 113 with itself as the hub.

FIG. 3 illustrates a situation in which a drone 118, transiting through an altitude-limited authorized airspace 305, will encounter obstructions collectively indicated at 310 that it must fly around in order to remain within the airspace 305. This deviation from a preprogrammed flight path may be considerable, depending on the extent of the obstructions, and may require course corrections that the drone is not equipped to handle with great accuracy—potentially leading it to miss all or part of the target when it arrives there. With the HAPS 105 in communication with the drone 118, the HAPSNN predicts the need for additional airspace authorization and requests its extension to the region 315. Once the authorization is obtained, the HAPS 105 communicates the relaxation of the altitude restriction to the drone 118. In some embodiments, the HAPS 105 may compute a revised flight path 320 at higher altitude for the drone 118, enabling it to remain on course for the target without any lateral deviation that could affect navigation accuracy.

Similarly, in FIG. 4, the planned and authorized flight path 405 for the drone 118 would take it through a dangerous localized weather pattern, which the HAPS 105 detects with onboard radar or from real-time weather updates. The HAPSNN, aware of the drone's flight path and the weather condition, recognizes the need for an alternative flight segment 410, which it or another onboard computational module computes. The HAPS 105 obtains authorization for the new flight path 410 and communicates it to the navigation system of the drone 118.

FIG. 5 shows a drone 118 traveling through obstructions that prevent line-of-sight communication with cell towers 108 and a source 505 of National Airspace System navigational aid signals (such as VOR, VOR/DME, TACAN, etc.). The HAPSNN infers this condition from knowledge of terrestrial features within the airspace 115 and the state of the drone 118. As a consequence, the HAPSNN causes the HAPS 105 at least to relay the signals from the blocked sources 108, 505 or to establish a wireless link among the communicating entities 108, 118, 505 with itself as the hub.

In FIG. 6, a drone 605 is flying in its authorized airspace 610. A second drone 615 enters the airspace 610, and the HAPSNN detects that the drones 605, 615 are not communicating or cannot communicate; for example, one or both of the drones 605, 615 may be “uncooperative,” i.e., not equipped to communicate with other drones and de-conflict flight paths. The HAPSNN may infer this based on communication, or the absence thereof, between the drones and/or with ground-based air-traffic surveillance and monitoring systems. The HAPSNN determines that, to avoid collision, the drone 605 should follow an alternative flight path 620, which may be temporary until the drone 605 has passed the drone 615. The HAPSNN or another onboard computational module computes the new flight path 620. The HAPS 105 thereupon obtains authorization for the new flight path 620 and communicates it to the navigation system of the drone 605.

With reference to FIG. 7, a drone 118 may follow a flight path 705 within an authorized airspace corridor 707 to inspect or take data readings from a series of assets (e.g., a sequence of transformers 7101 ... 7105 along a power line 712) using, for example, an RFID reader. The HAPSNN monitors the data stream received by the drone 118 and, if the drone detects an anomaly, the HAPSNN may infer that the drone 118 will require a change to its airspace authorization; in particular, if the anomaly is associated with the transformer 7103, the predicted authorization need may encompass the region 720. The HAPSNN may cause the HAPS 105 to take action, e.g., relaying the information to appropriate UTM/LAANC systems or requesting a change to airspace authorization on behalf of the drone 118, which will then be free to inspect the transformer 7103 more closely and record images of it for real-time or later evaluation.

FIG. 8A illustrates a representative HAPSNN architecture 800, which includes the HAPS flight vehicle and various hardware and software elements. In general, a plurality of software subsystems, implemented as instructions stored in a computer memory, are executed by a conventional central processing unit (CPU) 802. The CPU 802 may control the flight and operation of the HAPS vehicle as well as the functions described below, or these functions may be allocated among separate processors 802. In addition, for efficient execution of neural-network functionality, the system may include a dedicated graphics processing unit. An operating system (such as, e.g., MICROSOFT WINDOWS, UNIX, LINUX, iOS, or ANDROID) provides low-level system functions, such as file management, resource allocation, and routing of messages from and to hardware devices (including at least one nonvolatile storage element 803) and the software subsystems, which execute within a computer memory 804. More generally, the HAPSNN 800 may include modules implemented in hardware, software, or a combination of both. For functions provided in software, programs may be written in any of a number of high level languages such as PYTHON, FORTRAN, PASCAL, JAVA, C, C++, C#, BASIC, various scripting languages, and/or HTML. The software modules responsible for operation of the HAPS vehicle, as well as the mechanical and flight features, are conventional and not illustrated; see, e.g., U.S. Pat. No. 10,618,654, the entire contents of which are hereby incorporated by reference.

The HAPSNN 800 includes a neural network module 805, a transceiver module 808, and a field-programmable gate array (FPGA) 810. The modules transceiver module 810 and the FPGA 810 may constitute, or be part of, a communication facility configured to support airborne communication among flight vehicles and with terrestrial and satellite-based control infrastructure. The HAPSNN 800 may (but need not) operate in conjunction with drones that are equipped with a DINN 812. The cloud neural network module 805 may be local to the HAPS vehicle but more typically operates in the cloud, i.e., on a remote (e.g., terrestrial) server in wireless communication with the HAPS vehicle as described below. The modules 808, 810 are typically located on the HAPS vehicle itself.

The cloud neural network module 805 includes a classification neural network 815 that processes images and data received, via agile transceivers 808, from a drone in real time, and which may be passed to the cloud neural network 805. The classification neural network 815 has been trained using a database 817 of training images relevant to the missions that monitored drones will undertake. The classification neural network 815 processes and classifies received images and data and detects—i.e., computes the probability of—anomalies associated therewith. That is, an anomaly may be detected based on something unexpected in a received image or when considered alongside other drone telemetry; for example, an otherwise unexceptional image may trigger an anomaly detection when taken in conjunction with weather conditions reported by the drone. When an anomaly is detected, the classification neural network 815 may consult a classification database 819 to determine the proper response; that is, the database 819 includes records each specifying an anomaly and one or more associated actions that may be taken in sequence. If anomalies are detected that do not have a database record, the images may be transmitted for human inspection and classification. New classifications are then added to the training database 817 and used to retrain the neural network 815. The resulting adjusted weights may be propagated, by the cloud server associated with the neural network 805, back to the DINN 812 (if there is one) transmitting drone and other drones in the field with similar mission profiles. This procedure is described further below.

The agile transceiver package 808 includes Automatic Dependent Surveillance Broadcast (ADS-B), Traffic Collision Avoidance System (TCAS), Secondary Surveillance Radar (SSR), and Automatic Dependent Surveillance Rebroadcast (ADS-R) subsystems that operate at 978 MHz, 1090 MHz, and 1030 MHz for interrogations, responses, and rebroadcasts. These enable the HAPSNN 800 to “listen” to the positions of manned air traffic so the neural network 815 can computationally represent nearby traffic in 3D or 2D space and resolve any conflicts between drones and manned air traffic. This can be achieved by broadcasting the position of a drone to manned air traffic or the positions of manned air traffic to the drone. Emergency alerts may be issued to manned and/or unmanned traffic with instructions on which way to move to deconflict the airspace.

The agile transceivers 808 may include a cellular network package including 3G, 4G, LTE, 5G or any future telecommunication protocol and bandwidth to support communication links between drones operating in the airspace of the HAPSNN 800, with the terrestrial telecommunications network that some UTM systems utilize, or with backhaul communications channels to transmit data from the HAPS to the cloud-based neural network. VHF and UHF transceiver (TX/RX) modules may be used to monitor navigational aids such as VORs, VOR/DMEs or TACANs that enable the neural network 805 to resolve the position of drones as well as of the HAPS using signal time of flight in the event GPS signal is lost. This also enables leveraging satellite communication constellations to transmit or receive data should the need arise. The drone virtual radar (DVR) data link facilitates communication with drone platforms that implement this technology (described, for example, in U.S. Pat. No. 10,586,462, the entire disclosure of which is hereby incorporated by reference) to send and receive air-traffic position information to help resolve conflicts or track drones. The neural network (NN) data link is a dedicated high-bandwidth backhaul channel that enables the HAPSNN 800 to communicate with DINN neural network compute engines 825, transmitting real-time data received from a plurality of drones operating in the monitored airspace and receiving predictions and action instructions obtained from the classification database 819. The FPGA 810 is employed as hardware accelerators to run software that tunes the transceivers 808 and filters out noise.

A representative DINN 812, implemented in a drone 118, includes a neural network compute engine 825, a classification database 825, and “back-end” code to perform various data-handling and processing functions as described below. In addition, the drone 118 includes a communication facility comprising or consisting of a set of agile transceivers 808 and an FPGA 810, as detailed above. Also, the drone 118 may include a CPU 802, storage 803, a computer memory 804.

As noted, although the DINN 812 may interact with a HAPSNN 800, either can exist and operate on its own; that is, a HAPSNN is unnecessary for successful deployment and use of a DINN, while a HAPSNN may perform its surveillance and safety roles for flight vehicles lacking DINNs. The role of the DINN 812 is to enable the drone 118 to classify objects of interest on an asset it is inspecting (e.g., recognizing a cell tower to be inspected and a cracked antenna on such a tower), as well as obstacles that it will need to avoid during flight. The neural network 825 is configured to process and classify images received from an image-acquisition device 827, e.g., a videocamera on the drone 118. Hence, the neural network 825 may be a convolutional neural network (CNN) programmed to detect and recognize objects in the incoming images. These may be classified based on the neural network's training and the DINN 812 (e.g., the back-end code) may consult a classification database 830 to determine the proper response to a detected image. In this case, the database 819 includes records each specifying an object associated with some semantic meaning or action. For example, if the neural network 825 detects a tree in an incoming image, the corresponding database entry may identify a tree as an obstacle and trigger an avoidance maneuver that the drone's navigation system 832 executes by controlling the drone's steering and propulsion system. These are part of the drone's flight package 835, which is conventional and therefore not shown in detail, but includes a power source, communications platform, the propulsion and steering systems, an autopilot system, etc.

The DINN 812 may also receive data from one or more surveillance systems 837, 839, which may include one or more of DVR, UTM, LAANC, ADS-B and TCAS systems. Although these may be implemented as part of the drone's communication platform, they are illustrated as conceptually within the DINN 812 since the neural network 825 may use this data in classifying an image. Similarly, while a weather surveillance system 842 would conventionally be implemented within the drone's communication platform, it is shown as part of the DINN 812 because, once again, weather conditions may be relevant to image classification or database lookup; as shown in FIG. 4, the same visual scene may prompt different actions depending on the weather, e.g., the drone 118 may give buildings a wider berth under windy conditions.

In embodiments where the drone 118 interacts cooperatively with a HAPSNN 800, the latter may provide further support and more powerful classification capabilities; for example, images with detected objects unclassifiable by the neural network 825 may be uploaded to the HAPSNN 800 for examination, and real-time instructions issued in return by the HAPSNN may be executed by the drone's navigation system 832. Moreover, the HAPSNN 800 may update or supply different weight files for the neural network 825 in real time to better fit the drone's mission based on the classifications that are being made by that drone (and which are communicated to the HAPSNN 800 in real time). The neural network 825 responsively loads these new weight files when received.

This process is illustrated in FIG. 8B. With reference also to FIG. 8A, the DINN 812 processes incoming image frames in real time (e.g., ˜30 frames per second (FPS)) to enable the drone 118 to react fast enough to avoid collisions and to fly around the tower 850. Accordingly, the drone 118 may a graphics-processing unit (GPU) to support CNN operations. Real-time frame analysis allows the GPU to process the images and classify items on interest on an asset being inspected, notify the back-end code of the classification, and enable the back-end code to execute logic to react to the classification—generally by performing a look-up in the classification database 830 to obtain action corresponding to the classification.

The drone 118 transmits image data to the HAPSNN, which includes a high-precision CNN (in the compute engine 815 or even within the HAPS itself, if desired) capable of processing, for example, a 60 Megapixel (MP) photographic image each second. The CNN architecture is designed for speed and accuracy of classification by leveraging back-end logic that runs on the compute engine 825. This back-end logic can change the CNN weight and configuration files based on the asset that is being classified based on the first few images of the asset captured by the drone. These preliminary images are collected as part of a “preliminary” flight path around the asset at a safe distance, and may be 60MP or greater in resolution. These preliminary images are downscaled to the CNN's input image size (e.g., 224×224, or larger depending on the asset to be inspected), and pass through a sequence (of, e.g., 20) convolutional layers, followed by an average pooling layer, and a fully connected layer pre-trained to classify different assets (e.g., 100 types of assets). Once the type of asset is identified, the weights and configuration files may be changed and more (e.g., four) convolutional layers are added followed by two fully connected layers to output probabilities and bounding boxes of objects or areas of interest that may be present on the asset. The images uploaded from the drone may be increased in size (e.g., to 448×448) as this type of classification requires more granular detail to be present. The degree of size increase may be dynamically controlled, e.g., scaled up if sufficient detail is not detected for reliable classification.

The fully connected layers predict the class probabilities and bounding boxes (i.e. cracked antenna, rust and corrosion, etc.). As an example, the final layer may use linear activation whereas the convolutional layers may use leaky ReLu activation.

Once the back-end logic of the compute engine 825 detects the presence of class and bounding box coordinates, it may switch to and trigger a centroid tracker function to bring that specific classification into the center of the field of view of the drone's image-acquisition device. The back-end logic cooperates with a ranging compute engine to resolve the safest flight path for the drone to approach and position the image-acquisition device for high-resolution scans.

Accordingly, the preliminary flight path establishes the type of asset in view and registers the position of the asset in 3D space relative to the drone to account for any GPS drift vectors. If there are any obstacles or hazards present in the operating area they are classified and their position in 3D space is registered. The centroid tracker is activated once a classification in area of interest is detected and keeps the object of interest centered in the field of view. The ranging compute engine controls forward and backwards movement of the drone. Before any of these commands are executed, the position of the drone in 3D space relative to the asset and any obstacles present in the operating area is obtained. This data runs through back-end logic that resolves a safe GPS waypoint flight path that will bring the drone to the area of interest—in GPS-denied areas, this flight path can still be resolved and executed using Kalman filtering of inertial data in conjunction with centroid and ranging functionality. The flight path is fine-tuned in real time via the centroid tracker and ranging compute engine. It should be noted that the centroid tracker can be run by a HAPSNN 800 rather than the DINN 812.

In step 855, the HAPSNN CNN (“HP-CNN”) processes each image to detect objects therein using a standard object-detection routine (e.g., YOLO), and attempts to identify (i.e., classify) all detected objects based on its prior training (discussed further below). Detected objects that cannot be identified are stored in a database and made available to personnel for identification and labeling (step 857). The HP-CNN is then retrained on an augmented dataset including the newly identified and labeled object data (step 859), resulting in generation of new CNN weights (step 862). If the real-time neural network 825 resident on the drone 118 is also a CNN (“RT-CNN”), the HAPSNN 800 may push these weights to the RT-CNN, which receives and loads them. That is, the HP-CNN and RT-CNN may be identical or substantially similar so that CNN weights generated for the HP-CNN may be propagated across a fleet of drones.

The HP-CNN (or, in some embodiments, an RT-CNN on its own) may be trained in a conventional fashion. In particular, the CNN is trained on labeled images of objects likely to be encountered by a drone as it executes its missions, yielding a CNN capable of analyzing and classifying the objects most likely to be encountered by drones in their typical flight paths. Because no training set can be exhaustive and drones will inevitably encounter unknown objects during use, the above-described process of spotting unrecognized objects, storing them for manual labeling, and thereafter retraining the CNN on the augmented dataset helps minimize the risk of mishap by constantly enriching the drones' visual vocabularies and action repertoires. Although this is most efficiently accomplished using a HAPSNN as a central training hub that receives unclassifiable objects from many drones and can keep all of their neural networks updated to reflect the latest classification capabilities, it is nonetheless possible to implement this training and retraining function on individual DINNs.

FIGS. 9A-13E illustrate various drone applications and the manner in which a DINN may be used to control and simplify drone operation. In FIG. 9A, the DINN 812 guides the drone 118 around an antenna 900 to be inspected in accordance with a flight pattern 910 that may change in real time as the drone 118 detects anomalies or structures requiring closer inspection. For example, as shown in FIG. 9B, the flight path 910 may be altered to keep the drone 118 clear of power lines 915, which will have been recognized as an obstacle.

With reference to FIG. 10, an antenna 1000 may have a crack 1005, which is identified by a DINN-equipped drone. The back end may execute an openCV function to fix a centroid on the antenna 1000 and move the drone to center the antenna in the field of view to facilitate image acquisition. This can be coupled with a depth map generated by stereo RGB cameras of known sensor size, lens properties, and camera focal point separation to position the drone 118 close enough to the antenna for the camera to resolve sufficient detail to pick up the cracks well. Other faults that may be recognized by the drone 118 include structural corrosion 1010 and a paint coating anomaly 1015. The drone 118 payload may include additional sensors, such as an EM sensor and an infrared camera, and the DINN 812 may include additional modules such as a spectral analysis and/or electromagnetic compute engine. These enable the drone 118 to detect a PIM signature at a coax connector 1025 and other EM anomalies such as magnetic fields emanating from a lightning arrestor 1030 (indicating the possibility of arcing), as well as an abnormal heat signature 1035. These conditions may be diagnosed as well as observed by the drone 118 or using onboard compute engines and/or in cooperation with a HAPSNN 800 as described above. The DINN 812 may further include a ranging compute engine to run data fusion between a depth map obtained as discussed above and laser rangefinder/radar/ultrasonic or any other ranging sensors that the drone payload may contain to derive the most accurate range readings; a computer vision compute engine to perform image-processing and analysis functions (such as centroid placement, as noted above); and/or an infrared and multispectral compute engine to analyze infrared and other images obtained at wavelengths outside the visible spectrum.

As shown in FIG. 11, if the drone 118 detects an unusual EM signature from an asset 1100—such as abnormal non-vertical magnetic field lines 1105, whereas under normal operation the field lines are vertical as indicated at 1110—it may record the anomaly or, in embodiments where the drone 118 is in communication with a HAPSNN, report it to the HAPSNN, which may autonomously summon a drone with a more specialized inspection payload to better diagnose the condition. The drone 118 may also communicate or otherwise interact with an asset to be inspected. In FIG. 12, a drone 118 reads data stored in a transformer 1200 indicating an abnormality. That is, the transformer 1200 has self-diagnostic capability and, when an operating anomaly was earlier detected, data indicative of the detection was stored internally. If the transformer 1200 is inspected regularly by a drone 118 and the anomalous condition does not require urgent attention, it may not be necessary for the transformer to communicate its presence to supervisory personnel upon detection. Rather, when the drone 118 makes an inspection flight, it can interrogate the memories of all transformers and thereby acquire previously stored data indicating transformer anomaly detections. This may prompt the drone 118 to perform a closer inspection (as indicated in the figure) in response to the classification of the condition and database lookup. Once again, a HAPSNN may recognize the condition and send new weights to the DINN of the drone 118, enabling it to make condition-specific classifications as it inspects the transformer 1200.

FIGS. 13A-13E show how a DINN 812 can establish an optimal flight path through a complex inspection environment. FIGS. 13A and 13B illustrate a power distribution substation 1300 including a series of outgoing transmission lines collectively indicated at 1310, a voltage regulator 1315, a stepdown transformer 1320, a series of switches 1325, one or more lightning arrestors 1330, and incoming transmission lines collectively indicated at 1335. Any of these components can develop anomalies or malfunction, and all may be inspected by a drone 118. As shown in FIGS. 13C and 13D, the drone 118 may execute a preliminary flight pattern 1350 to gather images for analysis by the DINN, alone or in concert with a HAPSNN. The DINN 812 analyzes images acquired by the drone's onboard camera and classifies the various components 1310-1335. Based on these classifications, the navigation module 832 (see FIG. 8) or back-end code computes an optimized flight plan 1355 that permits all of the components 1310-1335 to be properly and efficiently inspected by the drone 118. In greater detail, each component present in the substation 1300 is classified during the preliminary inspection flight path 1350, which is farther away from the substation 1300 to accommodate GPS drift vectors and other unknowns relating to obstacles or inaccuracies about the initial flight path. Once a component is classified, its position in the image, as well as that of the drone, is registered. This process repeats multiple times throughout the preliminary inspection and enables the back-end code to triangulate and position each of the classified assets in a 3D space so a more precise inspection flight path, which will bring the drone and payload closer to the assets, can be calculated. This new flight plan 1355 is then executed and again the DINN 812 classifies assets as the flight path is executed. In the preliminary inspection, the drone is farther away so the DINN 812 can only classify large items as the resolution of the image-acquisition device(s) is fixed. Once the closer flight path 1355 is executed, more asset detail will be detected, enabling the DINN 812 to classify new items and adjust the path of the drone again as needed. The ranging compute engine calculates the closest allowable approach distance between drone and an asset consistent with an acceptable safety margin.

Still another application in which a complex inspection operation may be optimized by a DINN is illustrated in FIG. 14. Here the objective is to detect and classify the “rad center”—i.e., the center of radiation 1410 _(R), 1415 _(R), 1420 _(R) of each of the antennas 1410, 1415, 1420, which are mounted to the telecommunication structure 1400 at different elevations. A DINN can classify a rad center and then identify, for each antenna, a centroid to bring the rad center into the center of the field of view of the drone camera so that a barometer reading (elevation) can be recorded. The navigation module 832 can then use this elevation to generate an orbit flight path that enables the drone 118 to obtain 3D model data for reconstruction of the antenna structure.

The terms and expressions employed herein are used as terms and expressions of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described or portions thereof. In addition, having described certain embodiments of the invention, it will be apparent to those of ordinary skill in the art that other embodiments incorporating the concepts disclosed herein may be used without departing from the spirit and scope of the invention. Accordingly, the described embodiments are to be considered in all respects as only illustrative and not restrictive. 

What is claimed is:
 1. A platform for high-altitude flight and communication with unmanned aerial vehicles (UAVs), comprising: a wireless transceiver; a computer memory; a communication facility for communicating, via the transceiver, with UAVs operating within a defined airspace; and a computer including a processor and electronically stored instructions, executable by the processor, for using data received from the UAVs as input to a predictor that has been computationally trained to identify actions to be taken based on a UAV state and a condition affecting its flight.
 2. The platform of claim 1, wherein the predictor is a neural network.
 3. The platform of claim 1, wherein the computer is further configured for communication with air-traffic control infrastructure.
 4. The platform of claim 3, wherein the UAV state comprises a spatial position and a velocity, the computer being further configured to determine terrestrial features and their likelihood of interfering with current or future communications between a UAV and a terrestrial communication source and, if the likelihood exceeds a threshold, to establish a communication link bridging the UAV and the terrestrial communication source.
 5. The platform of claim 4, wherein the terrestrial features are determined based on a locally or remotely stored map.
 6. The platform of claim 3, wherein the UAV state comprises a spatial position and a velocity, the computer being further configured to (i) predictively determine a need for an altered flight plan for the UAV, and (ii) cause the transceiver to wirelessly obtain authorization for the altered flight plan and thereupon communicate the authorized altered flight plan to the UAV.
 7. The platform of claim 6, wherein the altered flight plan avoids a possible hazard.
 8. The platform of claim 7, wherein the hazard is a weather condition.
 9. The platform of claim 7, wherein the hazard is possible collision with another UAV.
 10. The platform of claim 6, wherein the altered flight plan permits unplanned inspection of a terrestrial asset.
 11. A method of controlling a defined airspace using a high-altitude pseudosatellite vehicle, the method comprising the steps of: wirelessly monitoring a state of at least one unmanned aerial vehicle (UAV) operating in the defined airspace; detecting flight-affecting conditions in the defined airspace; using data received from the at least one UAV as input to a predictor that has been computationally trained to identify actions to be taken based on the UAV state and a detected flight-affecting condition; and causing the high-altitude pseudosatellite vehicle to responsively take the action.
 12. The method of claim 11, wherein the predictor is a neural network.
 13. The method of claim 11, wherein the action includes communication with air-traffic control infrastructure.
 14. The method of claim 13, wherein the UAV state comprises a spatial position and a velocity, and further comprising the steps of: determining terrestrial features and their likelihood of interfering with current or future communications between a UAV and a terrestrial communication source; determining that the likelihood exceeds a threshold; and thereupon establishing a communication link bridging the UAV and the terrestrial communication source.
 15. The method of claim 14, wherein the terrestrial features are determined based on a locally or remotely stored map.
 16. The method of claim 13, wherein the UAV state comprises a spatial position and a velocity, and further comprising the steps of: computationally determining a predicted need for an altered flight plan for the UAV; and thereupon wirelessly obtaining authorization for the altered flight plan and communicating the authorized altered flight plan to the UAV.
 17. The method of claim 16, wherein the altered flight plan avoids a possible hazard.
 18. The method of claim 17, wherein the hazard is a weather condition.
 19. The method of claim 17, wherein the hazard is possible collision with another UAV.
 20. The method of claim 16, wherein the altered flight plan permits unplanned inspection of a terrestrial asset. 